Capitolul I Selectarea strategiei de proiectare a sistemelor 
informatice 
(De la analiza la proiectarea sistemelor informatice) 


Obiectivul principal urmărit în faza de analiză l-a reprezentat definirea 
a „ceea ce este” şi a „ceea ce ar trebui să fie” sistemul informaţional. În 
acest sens au fost realizate două activităţi importante: determinarea 
cerinţelor sistemului şi structurarea  (formalizarea) acestora. Prin 
determinarea cerințelor sistemului s-a urmărit mai întâi descrierea a ceea ce 
face sistemul existent prin prezentarea proceselor de prelucrare, a fluxurilor 
informaţionale, a procedurilor de lucru, a documentelor şi rapoartelor din 
sistem etc. Apoi, s-a urmărit identificarea a ceea ce doresc utilizatorii de la 
noul sistem. Structurarea cerinţelor sistemului a vizat dezvoltarea modelului 
logic al sistemului. Fluxurile informaţionale dintre procesele de prelucrare au 
fost reprezentate prin diagrama fluxurilor de date, logica prelucrării datelor a 
fost descrisă prin intermediul tabelelor de decizie sau a englezei structurate, 
modelul conceptual al datelor a fost transpus prin intermediul diagramei 
entitate-relatie. 

Odata finalizata faza de analiza, trebuie aleasa calea ce va fi urmata 
pentru obtinerea noului sistem. Asadar, punctul in care ne aflam acum il 
reprezintă trecerea de la analiza sistemului la proiectarea sitemului. 
Obiectivul principal al proiectării constă în a determina exact „cum” se va 
parcurge drumul de la „ceea ce este” la „ceea ce ar trebui să fie” sistemul 
pentru a se îngloba toate cerinţele identificate anterior. Proiectarea trebuie să 
ofere soluţia optimă de înglobare a tuturor cerinţelor în noul sistem. Trecerea 
de la analiză la proiectare presupune trecerea de la „ce” la „cum” se va obţine 
noul sistem. Toate informaţiile obţinute până acum trebuie transformate în 
idei şi soluţii de proiectare pentru noul sistem. 

Direcţia care va fi urmată în continuare în dezvoltarea noului sistem 
este numită strategia de proiectare. Chiar dacă după parcurgerea fazei de 
analiză multe lucruri s-au clarificat, mai există unele incertitudini privind 
sistemul datorate contradictiilor care pot exista între utilizatori privind 
cerinţele funcţionale, alternativele privind platformele hardware şi software, 
cerinţele funcţionale care să fie incluse în noul sistem în funcţie de restricţiile 
de costuri şi timp, sursele de obţinere a software-ului etc. Echipa de realizare 
trebuie să identifice şi să definească clar câteva alternative de proiectare a 
sistemului pe care să le supună dezbaterii utilizatorilor şi conducerii firmei, 
din care va fi aleasă cea optimă. 

În prezentul capitol ne vom ocupa de principalele aspecte care privesc 
definirea strategiei de proiectare. Vor fi prezentate activităţile care trebuie 
parcurse, consideratiile care stau la baza generării alternativelor strategice 
de proiectare, criteriile utilizate la evaluarea alternativelor, modul de 
selectare a celei mai bune variante de sistem. 


1.1 Consideraţii generale privind strategia de proiectare 


După cum spuneam anterior, înainte de trecerea la proiectarea noului 
sistem trebuie aleasă strategia de proiectare, ceea ce implică identificarea 
mai multor variante de proiectare şi alegerea celei optime. Dar de ce este 
nevoie să definim mai multe variante de proiectare? 


Mai întâi să spunem că în domeniul dezvoltării sistemelor 
informaţionale, ca de-altfel în mai toate domeniile de activitate, se aplică 
demersul sistemic de rezolvare a unei probleme. Acest demers presupune 
parcurgerea unor faze şi etape interdependente şi care se întrepătrund, 
prezentate în figura 1.1. După cum se poate uşor observa, primele două faze 
au fost parcurse deja, de următoarele trei ne vom ocupa în acest capitol, iar 
ultimele două vor fi abordate în cadrul celorlalte capitole. 

Desigur că răspunsul ar putea fi considerat ca “evaziv”. De ce trebuie 
aplicat demersul sistemic? Care sunt avantajele aplicării lui în domeniul 
dezvoltării sistemelor informaţionale? 
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Figura 1.1 Fazele şi etapele demersului sistemic de rezolvare a unei probleme 
(O'Brien, J., Les systemes d’information de gestion, DeBoeck Universite, Montreal, 1995, p. 
72) 


Un vechi dicton ingineresc spune că “Un proiect poate fi de bun, ieftin 
şi realizat în timp scurt . . . alege două dintre ele”. Marakas a denumit 
aplicarea acestui dicton în domeniul sistemelor informaţionale ca adevărul 
geometric despre proiectele de dezvoltare a sistemelor informaţionale, 


pornind de la teorema lui Pitagora!. Aşa cum la trasarea unui triunghi se 
poate specifica doar mărimea a două unghiuri (al treilea fiind determinat ca 
diferenţă până la 180 de grade), la fel şi în dezvoltarea sistemelor 
informaţionale trebuie găsit un echilibru între calitatea, costurile şi timpul de 
realizare (vezi figura 1.2). Accentul pus pe unul din cele trei aspecte se va 
răsfrânge asupra unuia din celelalte două sau asupra ambelor aspecte. De 
exemplu, accentul pus pe calitatea sistemului (cum ar fi includerea tuturor 
cerinţelor funcţionale şi nefunctionale în sistem) ar presupune costuri şi timp 
de realizare mai mari. Dacă se doreşte minimizarea costurilor şi reducerea 
timpului de realizare, atunci calitatea sistemului va fi mult afectată. Obţinerea 
unui sistem de calitate şi într-o perioadă scurtă de timp duce la sporirea 
considerabilă a costurilor (vor trebui angajaţi numeroşi specialişti din afara 
firmei). Prin urmare, se poate interveni doar asupra a două din cele trei 
aspecte importante care privesc dezvoltarea sistemelor informaţionale. 

Decizia asupra soluţiei optime trebuie să o ia utilizatorii şi conducerea 
firmei, datorită importanţei ei deosebite. După luarea acestei decizii şi 
trecerea la proiectarea şi implementarea sistemului orice revenire poate fi 
foarte costisitoare sau chiar imposibilă. Orice revenire până în acest punct 
poate să nu implice nici un cost suplimentar. După stabilirea strategiei de 
proiectare şi trecerea la implementarea ei face dificilă orice revenire cu atât 
mai mult cu cât s-a înaintat în realizarea proiectului. Dacă s-a optat pentru 
dezvoltarea aplicaţiilor în mediul FoxPro, nu se poate reveni uşor pentru 
trecerea la mediul Oracle deoarece s-a constatat că nu pot fi satisfăcute 
cerinţele de securitate. Acest lucru ar însemna renunţarea la o mare parte din 
rezultatele obţinute până în momentul respectiv. 
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Prin urmare, cea mai buna solutie de proiectare a sistemului trebuie 

să asigure compromisul optim între cele trei dimensiuni: calitatea sistemului, 

costurile şi timpul de realizare. Găsirea acestui optim implică identificarea 

mai multor variante şi evaaluarea cu atenţie a acestora cu scopul alegerii 
celei mai bune. 

Un alt motiv care justifică necesitatea elaborării mai multor 

alternative de proiectare este legat de pericolul familiarizării excesive a 
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membrilor echipei cu anumite tipuri de probleme?. Dacă ei sunt specializaţi cu 
precădere în tehnologia bazelor de date, atunci soluţia lor se va baza pe 
această tehnologie, chiar dacă cel mai indicat mod de rezolvare ar consta în 
utilizarea unui program de calcul tabelar. De asemenea, dacă în trecut au 
avut o soluţie anume la un gen similar de problemă, varianta propusă de ei va 
fi ultima lor realizare la dezvoltarea unui alt sistem. Dacă ea ar fi şi cea mai 
bună soluţie nu ar fi nimic grav, însă, de multe ori, propunerea este 
subiectivă. 

Definirea strategiei de proiectare presupune două activităţi principale: 

e Generarea alternativelor strategice de proiectare si 
e Selectarea celei mai bune variante. 

În continuare vom aborda aceste două probleme. La generarea 
alternativelor de proiectare sunt luate în considerare aria de întindere şi 
nivelul de informatizare, definirea mediului de dezvoltare a aplicaţiilor şi 
sursele de obţinere a software-ului. 


1.2 Selectarea alternativelor privind aria de întindere şi nivelul de 
informatizare 


Una dintre activităţile realizate în faza de analiză a constituit-o 
definirea ariei de întindere a sistemului. Obiectivul urmărit atunci a fost 
definirea graniţelor sistemului prin identificarea funcţiilor ce vor fi incluse şi a 
legăturilor cu mediul său extern. Toate aceste informaţii au fost structurate 
cu ajutorul diagramelor fluxurilor de date. Un rol important l-au jucat 
utilizatorii, care şi-au specificat cerinţele funcţionale. 

Acum, înainte de a se trece la proiectarea sistemului, echipa de 
realizare a trebuie să se decidă asupra funcţiilor care vor fi incluse în sistem. 
De regulă, utilizatorii solicită mai multe cerinţe funcţionale a căror satisfacere 
ar duce la depăşirea bugetului alocat şi/sau a timpului de realizare planificat. 
Mai mult, se întâmplă care utilizatorii să ceară adăugarea unor noi funcţii 
după ce s-a trecut la faza de proiectare. Astfel de situaţii pot fi evitate prin 
formalizarea procesului de identificare, grupare şi stabilire a priorităţii 
cerinţelor informaţionale. În acest sens, echipa de realizare a sistemului va 
întocmi un document cu care utilizatorii să fie de acord şi pe care-l vor semna. 
În el vor fi consemnate toate cerinţele utilizatorilor. 

Pentru a decide asupra funcţiilor (crintelor funcţionale) ce vor fi 
incluse în sistem este necesară definirea unor alternative de proiectare. 
Fiecare alternativă va îngloba mai puţine sau mai multe din cerinţele 
utilizatorilor. Această sarcină poate fi uşurată prin gruparea cerinţelor 
sistemului în trei categorii: obligatorii, importante şi dorite. Stabilirea 
priorităţii fiecărei cerinţe este efectuată împreună cu utilizatorii şi poate fi 
realizată chiar în faza de analiză, pe măsură ce acestea sunt identificate. 

Determinarea prioritatii fiecărei funcţii se face, de regulă, în strânsă 
legătură cu descrierea nivelului de informatizare a sistemului. Nivelul de 
informatizare priveşte suportul pe care sistemul informatic îl va oferi pentru 
fiecare funcţie în parte. Pentru cele mai multe funcţii ale unui sistem, pot fi 
definite cel puţin trei niveluri de informatizare: mic, mediu şi mare. În cazul 
unui nivel mic de informatizare, sistemul se va limita la gestiunea 
înregistrărilor care privesc acea funcţie. Aplicația va conţine formulare pentru 
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introducerea, modificarea, validarea şi salvarea datelor şi va furniza unele 
informaţii sub forma rapoartelor programate. Un nivel mare de informatizare 
presupune ca sistemul să realizeze cât mai multe din prelucrările specifice 
funcţiei respective. Definirea acestui nivel este foarte dificilă. Dacă în cazul 
unui nivel mic de informatizare se urmăreşte, de regulă, doar automatizarea 
procedurilor manuale existente, acum trebuie sesizate noi moduri de lucru, 
trebuie regândit complet modul de realizare a acelei funcţii, cu scopul 
îmbunătăţirii radicale a performanţelor. Acest cadru mai este întâlnit sub 
numele de reproiectarea proceselor economice (Business Process 
Reengineering - BPR). Varianta nivelului mediu de informatizare reprezintă 
de obicei o combinaţie a caracteristicilor celorlalte două alternative. Prin 
această variantă, care este cel mai probabil să fie selectată, analistul încearcă 
să facă cea mai bună alegere între ceea ce este necesar şi ceea ce este 
posibil, ţinând cont de restricţiile privind bugetul şi timpul alocate. 

După definirea alternativelor de proiectare, pe baza prioritatii si 
nivelurilor de informatizare pentru fiecare funcţie, se trece la evaluarea 
acestora. Drept criterii de evaluare vor fi utilizate în primul rând restricţiile 
rezultate din studiile de fezabilitate a proiectului. Este evident că extinderea 
funcţională a sistemului şi un nivel ridicat de informatizare vor implica 
costuri mari şi timp îndelungat. În această fază, informaţiile despre cerinţele 
sistemului şi dificultatea dezvoltării unor capacităţi ale acestuia sunt mai 
detaliate, echipa de dezvoltare fiind în măsură să evalueze mai exact decât în 
fazele anterioare costurile pentru fiecare alternativă strategică de proiectare, 
urmărindu-se încadrarea în bugetul aprobat. Datorită şi restricţiilor de timp, 
noul sistem nu va putea satisface toate cerinţele utilizatorilor. Însă, pe măsură 
ce utilizatorii capătă experienţă în lucrul cu noul sistem, aceasta poate fi 
extins până ce se acoperă toate cerinţele şi se obţine nivelul de informatizare 
dorit. 


Exemplu 

În continuare, vom prezenta un exemplu prin care să punem în 
evidenţă modul în care pot fi identificate şi definite alternativele de proiectare 
legate de aria şi nivelul de informatizare. 

Considerăm sistemul de urmărire a vânzărilor pentru o firmă 
distribuitoare de carte. In urma definirii ariei de întindere, într-o forma 
simplificată, sistemul pus în discuţie realizează următoarele funcţii principale: 

e Evidenţa comenzilor. După primirea comenzii se verifică 
situaţia clientului şi a stocului pentru produsele solicitate, iar în 
cazul avizării se calculează valoarea comenzii, se emite şi 
transmite o înştiinţare către client şi se înregistrează comanda. 

e Prelucrare stocuri. Pe baza solicitării clientului se confirma 
existenţa stocului necesar, se emite avizul de expediţie, un 
exemplar fiind transmis la depozit, şi se actualizează stocul. 

e Onorare comenzi. Avizul de expediţie stă la baza întocmirii 
facturii, după care are loc înregistrarea şi transmiterea ei către 
client. Datele privind facturile sunt prelucrate zilnic în vederea 
întocmirii notei contabile ce este transmisă, împreună cu 
documentele justificative, către sistemul de contabilitate 
generală. 

e Evidenta analitică clienţi. Acest proces este necesar pentru 
întocmirea situaţiei clienţilor de încasat şi determinarea 


clienţilor în litigiu. În acest sens se deschide câte o fişă analitică 
pentru fiecare client important. 
° Analiza vânzărilor. Acest proces presupune agregarea datelor 
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Figura 1.3(a) Informatizarea completă a sistemului de urmărire a vânzărilor 


După cum vom vedea în continuare, diagramele fluxurilor de date sunt 
foarte utile în definirea alternativelor de proiectare. În figura 1.3(a), s-a optat 
pentru informatizarea întregului sistem informaţional. Informatizarea poate 
începe din momentul în care se primeşte comanda de la client (eventual prin 
poştă), însă poate merge până la dezvoltarea unei aplicaţii Web care să 
permită clienţilor care au acces la Internet să introducă comanda direct în 
sistem. Clienţii vor putea astfel comanda produse 24 din 24 de ore. In plus, s- 
ar putea crea un site în care clienţii să găsească informaţii cu privire la 
produse sau la starea comenzilor lansate de ei. Eventual, sistemul ar putea să 
recomande clienţilor şi alte cărţi, în funcţie de cele comandate (de exemplu 
alte cărţi ale autorilor pentru cărţile comandate sau alte cărţi cu subiecte 
asemănătoare sau complementare). În continuare, avizarea comenzilor se 
poate face tot automat, prin implementarea în aplicaţie a unor reguli şi 
politici de creditare stabilite de conducere, precum şi calculul valorii comenzii 
şi emiterea instiintarii. Nivelul de informatizare poate fi sporit prin 
transmiterea electronica a instiintarii. 

Pe baza comenzii primite, si dupa avizarea acesteia, se emite automat 
avizul de expeditie si factura, dupa care urmeaza inregistrarea lor si 
generarea automata a notei contabile la sfarsitul fiecarei zile. O facilitate 
suplimentara legata de prelucrarea stocurilor ar consta in comandarea 
automata la edituri a cartilor pentru care exista cerere si stocul este 
insuficient. 


Informatizarea completă a evidenţei analitice a clienţilor ar putea 
presupune şi determinarea profilului clienţilor pe baza datelor privind 
istoricul vânzărilor, ceea ce ar permite generarea unor oferte specifice 
fiecărui client în parte. 

Informatizarea analizei vânzărilor ar presupune doar generarea unor 
diverse rapoarte pentru conducere, fie dezvoltarea unei aplicaţii OLAP care să 
aibă la bază un depozit de date (Data Warehouse) care să permită analiza 
multidimensională a datelor. 

În figura 1.3(b) este pusă în evidenţă o variantă de informatizare 
parţială a sistemului. Se poate observa că prelucrarea stocurilor nu mai este 
informatizată, ceea ce înseamnă că avizul de expediţie se întocmeşte manual 
la depozit, la fel ca şi operarea stocurilor. De asemenea, s-a renunţat la 
generarea automată a notelor contabile, această funcţie fiind preluată de 
sistemul de contabilitate, căruia îi va fi transmisă factura. Şi analiza 
vânzărilor este plasat în afara ariei de informatizare, optându-se eventual pe 
generarea manuală a unor rapoarte ad-hoc cerute de conducere. 
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Figura 1.3(b) Informatizaarea parțială a sistemului de urmărire a vânzărilor 


Atunci când se pune în discuţie definirea ariei de informatizare trebuie 
să se lucreze la un nivel de granulaţie mai fin. Altfel spus, această discuţie nu 
se limitează la stabilirea proceselor din diagrama de „nivel 0” care să fie sau 
nu informatizate, ci trebuie luate în considerare şi subprocesele fiecărei 
funcţii din diagrama de „nivel 0”. De aceea, vor trebui luate în considerare şi 
diagramele de pe nivelurile inferioare. O prezentare mai detaliată a diferitelor 
variante de informatizare a principalelor procese din sistem este prezentată în 
tabelul 1.1. 

În general, pentru fiecare funcţie pot fi definite cel puţin trei niveluri 
de informatizare: nivelul inferior, nivelul mediu şi nivelul superior. In tabelul 
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1.1 sunt prezentate atât aria de cuprindere (prin încadrarea funcţiilor 
sistemului în una din cele trei categorii de proritati), cât şi nivelul de 
informatizare pentru fiecare funcţie în parte (prin prezentarea variantelor de 
informatizare). Stabilirea prioritatii se efectuează în funcţie de cerinţele 
utilizatorilor şi obiectivele sistemului. De exemplu, dacă unul din obiectivele 
sistemului vizează îmbunătăţirea relaţiilor cu clienţii, atunci funcţiile care 
permit firmei să răspundă mai rapid şi mai bine la cerinţele clienţilor vor fi 
obligatorii şi se va lua în considerare un nivel de informatizare cât mai bun. 


Tabelul 1.1 Prioritatile şi nivelul de informatizare al principalelor funcții 


Nivelul superior de 
informatizare 


Introducerea on-line a 
comenzii direct de către 
client 


Notificarea automată 


Verificarea în timp real 


Web 


de către clienţi prin 


Verificarea în timp real 


Web 


de către clienţi prin 


transmiterea automată 
prin e-mail 


transmiterea comenzii 
prin Web 


Generare şi 


Rezervarea stocului de 
către client odată cu 


Afişare on-line în timp 
real 


Afişare on-line în timp 
real 


Afişare on-line în timp 
real 


Generare notă contabilă |Generare notă contabilă 
lunar pentru fiecare 
tranzacţie 


Funcţiile  |Categori Nivelul inferior| Nivelul mediu de 
sistemului a de de informatizare 
prioritat | informatizare 
e 
Înregistrare Obligator [Introducerea 
comandă ie datelor de către 
un angajat la 
intervale 
regulate de timp 
Controlul stării |Dorită Oferirea 
comenzii răspunsului după 
un anumit timp 
Verificare Importan |Generarea 
situaţie client |tă periodică a 
listelor cu 
stocuri 
Verificare stoc |Dorita Generarea 
periodică a 
listelor cu 
stocuri 
Înştiinţare Importan Generare şi transmitere 
client tă prin e-mail după un 
anumit timp 
Transmitere Dorită Materiale Materiale personalizate 
materiale generale pe baza chestionarelor 
promoţionale 
Determinare Dorită Chestionare şi Analiza istoricului 
profil clienţi prelucrarea lor  |vânzărilor 
Actualizare stoc|Dorită Actualizarea 
periodică a 
stocurilor 
Generare Obligator 
situaţie clienţi lie 
de încasat 
Generare Obligator 
situaatie clienţi lie 
în litigiu 
Generare fişă |Importan 
client tă 
Generare notă |Dorită Generare 
contabilă recapitulatie 
tranzactii 
Analiză vânzări |Dorită 


Instrumente OLAP 
pentru analiza datelor 


Fiecare celulă din ultimele trei coloane trebuie detaliată într-o 
documentaţie separată. 

După cum se poate uşor sesiza, informatizarea anumitor funcţii 
depinde de nivelul de informatizare a altor funcţii. De exemplu, transmiterea 
de materiale promoţionale personalizate nu ar fi posibilă fără definirea 
profilului clienţilor pe baza analizei istoricului vânzărilor. De aceea trebuie 
urmărite cu multă atenţie diagramele fluxurilor de date. Neacordarea atenţiei 
cuvenite poate duce la situaţia în care sistemul să fie ineficient. De regulă se 
renunţă la informatizarea activităţilor situate la extremitatea fluxului logic al 
activităţilor din sistem. 

În concluzie, diagrama fluxurilor de date joacă un rol important nu 
doar în reprezentarea logică a prelucrărilor din sistem, ele stând şi la baza 
definirii alternativelor strategice de proiectare a sistemului, permiţând 
selectarea proceselor de prelucrare ce vor fi informatizate şi a modului în 
care va fi realizată. 

Evaluarea alternativelor de proiectare se face pe baza studiilor de 
fezabilitate efectuate, urmărindu-se în primul rând încadrarea în bugetul 
aprobat şi perioada de timp stabilită. Echipa de realizare poate cere 
suplimentarea bugetului şi prelungirea timpului necesar pentru dezvoltare, 
justificând conducerii necesitatea înglobării anumitor funcţii în sistem. În 
tabelul 1.1 sunt evidenţiate funcţiile care vor fi informatizate şi nivelul de 
informatizare ales. 


1.3 Definirea mediului de dezvoltare al aplicaţiilor 


Unul din aspectele importante ale dezvoltării unui nou sistem 
informaţional priveşte mediul de dezvoltare al aplicaţiilor. Mediul de 
dezvoltare face referire la configuraţia echipamentelor, a sistemelor de 
operare şi a reţelei în care vor fi instalate noile aplicaţii. Pentru a determina 
mediul de dezvoltare trebuie găsite răspunsurile la unele întrebări precum: 
Aplicațiile necesită prelucrarea pe loturi a unui volum mare de date sau 
prelucrarea on-line? Câţi utilizatori vor fi, câte posturi de lucru şi cât de 
răspândite vor fi acestea? Unde ar trebui localizate datele? Răspunsurile la 
aceste întrebări (şi multe altele) oferă o imagine preliminară asupra viitorului 
sistem, permiţând echipei de realizare a proiectului să ia deciziile potrivite 
pentru mediul de dezvoltare. 

In general, dezvoltarea noului sistem nu implică redefinirea mediului 
de dezvoltare. Aceste aspecte sunt extrem de importante, ele fiind luate în 
considerare, de regula, în faza planificării strategice a sistemelor 
informaţionale. În fapt, ar fi imposibilă redefinirea mediului de dezvoltare cu 
ocazia fiecărui proiect de realizare a unui nou sistem, fie şi numai pentru că 
ar afecta buna funcţionare a aplicaţiilor dezvoltate anterior. Totuşi, unele 
modificări pot fi aduse astfel încât să se obţină maximum de performanţe ale 
noului sistem sau utilizarea unor tehnologii noi. 

Prin urmare, analistul trebuie să ia în considerare la formularea 
alternativelor strategice de proiectare şi alternativele care privesc mediul de 
dezvoltare al aplicaţiilor. In continuare vom prezenta pe scurt câteva variante 
posibile: prelucrarea pe loturi/prelucrarea on-line, sistem 
centralizat/distribuit, internet/intranet/extranet. 


1.3.1 Alternativa sistem centralizat/sistem distribuit 


Atunci când vorbim despre mediul de dezvoltare a unui sistem 
informatic, pot fi identificate trei variante de sisteme: centralizate, 
descentralizate şi distribuite. De-a lungul evoluţiei informaticii, în diferite 
perioade a predominat una sau alta dintre aceste variante. 

Până la începutul anilor ’70, nu exista o altă variantă decât informatica 
centralizată. Sistemele informatice aveau la bază calculatoare de tip 
mainframe pe care erau rezidente toate aplicaţiile şi la care erau conectate 
terminale plasate în diferite locaţii din firmă. Aceste terminale permiteau doar 
introducerea datelor şi afişarea rezultatelor prelucrării. Moda centralizării a 
revenit la sfârşitul anilor '80 şi începutul anilor ‘90, atunci când au apărut şi 
s-au dezvoltat rețelele de calculatoare în care erau conectate 
microcalculatoare de tip IBM PC. 

La începutul anilor '80, odată cu proliferarea microcalculatoarelor, s-a 
dezvoltat informatica descentralizată. Majoritatea sistemelor informatice din 
această perioadă constau în aplicaţii izolate instalate pe PC-uri. Fiecare 
departament era dotat cu PC-uri pe care rulau aplicaţiile necesare 
desfăşurării activităţii lor. Marele merit al acestei scurte “epoci” a fost 
mutarea informaticii dintr-un departament special spre celelalte 
departamente funcționale din firmă însă, lipsa integrării aplicațiilor au creat 
numeroase neajunsuri, ceea ce a determinat în scurt timp reorientarea către 
informatica centralizată. 

La începutul anilor '70, odată cu apariţia minicalculatoarelor, au fost 
dezvoltate primele sisteme informatice distribuite. Aplicațiile sistemului erau 
distribuite pe mai multe minicalculatoare interconectate în rețea. Informatica 
distribuită a fost abandonată datorită aparitei microcalculatoarelor, dar s-a 
revenit în anii '90, odată cu maturizarea reţelelor de calculatoate şi a altor 
tehnologii informaţionale. În prezent se înregistrează tendinţa spre 
dezvoltarea sistemelor distribuite conform modelului client/server, asupra 
căruia vom reveni. 

Dacă problema sistemelor informatice descentralizare nu se mai pune 
astăzi, în schimb sistemele centralizate şi cele distribuite rămân alternativele 
viabile pentru dezvoltarea sistemelor informaţionale. Prin comparaţie, un 
sistem informatic centralizat presupune ca un singur calculator să satisfacă 
nevoile organizaţiei, la care pot fi conectate mai multe terminale (PC-uri sau 
NC-uri), iar un sistem distribuit va fi format din mai multe calculatoare pe 
care sunt distribuite aplicaţiile şi care împreună satisfac nevoile organizaţiei. 
Problematica sistemelor distribuite este mult mai complexă, motiv pentru 
care vom insista asupra ei în continuare. 

Sistemele distribuite pot fi definite ca “o colecţie de calculatoare 
independente care apar utilizatorilor acestora ca un singur sistem coerent”?. 
Această definiţie evidenţiază două aspecte esenţiale: primul priveşte 
hardware-ul - calculatoarele sunt autonome; cel de-al doilea vizează 
software-ul - utilizatorii au impresia că lucrează cu un singur sistem. 

Dincolo de această definiţie, problematica sistemelor distribuite poate fi 
clarificată prin prezentarea caracteristicilor lor esenţiale. Pe scurt, acestea 
sunt: 


3 Tanenbaum, A.S., van Steen, M., Distributed Systems. Principles and Paradigms, Prentice- 
Hall, Inc., Upper Saddle River, New Jersey, 2002, p. 2 
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> diferenţele dintre variatele tipuri de calculatoare şi modul în care 
ele comunică sunt ascunse (transparente) pentru utilizator, la fel ca 
şi organizarea internă a sistemului distribuit; 

> utilizatorii şi aplicaţiile pot interactiona cu un sistem distribuit într-o 

manieră uniformă şi consistentă, indiferent de locul şi momentul în 
care are loc interacţiunea; 

> execuţia concurentă a programelor reprezintă regula într-un sistem 

distribuit. Doi utilizatori îşi pot realiza sarcinile lor de lucru pe 
propriile calculatoare prin partajarea unor resurse, precum paginile 
web sau fişiere, atunci când este necesar; 

> sistemele distribuite trebuie să fie scalabile adică, să poată fi uşor 

extinse. Această caracteristică este o consecinţă directă a 
autonomiei calculatoarelor din sistem, dar şi a faptului că pentru 
utilizator organizarea internă este transparentă; 

> un sistem distribuit trebuie să asigure independenţa fata de 

eventualele căderi sau disfunctionalitati ale unor calculatoare sau 
aplicaţii din sistem, el trebuind să fie în continuare disponibil 
utilizatorilor. Este responsabilitatea proiectantilor de a prevedea 
consecintele eventualelor disfunctionalitati. 

Conceptul de sistem distribuit este aplicat unei mari varietati de 
configuratii si aplicatii. Totusi, pornind de la cele doua componente principale 
ale unui software - prelucrarile si datele, pot fi identificate doua tipuri de 
baza de sisteme distribuite: sisteme cu prelucrari distribuite si sisteme 
cu date distribuite. Exista mai multe variante de configurare a unui mediu 
cu prelucrari distribuite: aplicatiile pot fi stocate intr-o singura locatie si 
accesate de catre oricare procesor conectat in sistem; o aplicatie poate fi 
replicata pe mai multe locatii din retea; diferite aplicatii pot fi rezidente pe 
diferite locatii din retea, insa ele sunt accesibile tuturor utilizatorilor din 
retea. Distribuirea datelor presupune proiectarea unei baze de date 
distribuite in care datele sunt fragmentate si dispersate pe diferite locatii din 
retea sau ele sunt replicate pe mai multe noduri din retea in vederea usurarii 
accesului la date. O alta configuratie de sistem distribuit poate rezulta prin 
combinarea celor doua tipuri de baza, adica distribuirea atat a datelor cat sia 
prelucrarilor. 

Motivatia principală pentru utilizarea sistemelor distribuite o reprezintă 
dorinţa utilizatorilor de a partaja resursele. Noţiunea de resursă este una 
abstractă, folosită pentru a descrie mulţimea lucrurilor care pot fi partajate 
într-o reţea de calculatoare. Ea face referire la componentele hardware, 
precum discurile şi imprimantele, dar şi la cele software, precum fişierele, 
bazele de date, obiectele de toate tipurile. Partajarea resurselor nu este 
singurul avantaj al sistemelor distribuite, alte avantaje faţă de sistemele 
centralizate fiind enumerate în tabelul 1.2. 

Tabelul 1.2 Principalele avantaje şi dezavantaje ale sistemelor distribuite 


Avantaje Dezavantaje 
Creşterea disponibilitatii şi siguranţei Complexitatea sistemelor distribuite 
resurselor 
Reducerea costurilor de comunicaţie Sporirea dificultăţilor în controlul 

resurselor informaţionale 

Flexibilitatea dezvoltării sistemelor - Probleme legate de asigurarea 
creştere incrementală consistentei datelor 
Alinierea cu structura organizatorică a Sporirea dificultăţilor în testarea şi 
firmei detectarea erorilor 
Obţinerea unor timpi de răspuns mai buni 
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Independenţa faţă de tehnologiile unui 
singur furnizor 


Flexibilitatea dezvoltării sistemelor distribuite dată de faptul că o 
firmă aflată în plină dezvoltare (extindere) are posibilitatea de a adăuga 
incremental noi resurse (hard şi soft) în sistem, respectiv achiziţionarea, 
instalarea şi conectarea lor pe măsură ce ele sunt necesare. Flexibilitatea 
sistemelor centralizate este limitată de inabilitatea lor de a asigura creşterea 
incrementală. Dezvoltarea sau extinderea activităţii firmei determina 
supraîncărcarea sistemului informational existent si, implicit, necesitatea 
înlocuirii acestuia cu altul mai performant (în cazul sistemelor distribuite nu 
se pune problema înlocuirii acestuia ci a extinderii lui, conservându-se astfel 
investiţiile anterioare). Chiar dacă s-ar pune problema planificării extinderii 
viitoare a firmei în vederea dezvoltării unui sistem informatic corespunzător, 
soluţia unui sistem centralizat tot nu ar fi satisfăcătoare deoarece ea ar fi prea 
scumpă, atât timp cât o bună parte din capacitatea de stocare şi prelucrare a 
sistemului nu va fi utilizată decât ulterior, pe măsura dezvoltării firmei, şi 
numai dacă previziunile se adeveresc. 

Creşterea disponibilitatii resurselor reprezintă un alt avantaj major al 
sistemelor distribuite. Apariția unei  disfuncţionalităţi într-un sistem 
centralizat (căderea serverului sau a liniei de comunicaţie) determină 
blocarea întregului sistem informaţional până la remedierea problemei ivite. 
In schimb, sistemele distribuite sunt proiectate să funcţioneze şi în condiţiile 
apariţiei unor disfunctionalitati, care va afecta numai o parte a sistemului. 
Celelalte resurse rămân disponibile, ele putând chiar prelua sarcinile părţii de 
sistem afectate, situaţie în care utilizatorul nu va fi conştient de 
disfunctionalitatea apărută. 

Sistemele distribuite permit reducerea costurilor de comunicaţie şi 
depăşirea limitelor mediilor de comunicaţie. Într-un sistem distribuit, 
majoritatea prelucrărilor pot fi realizate local, iar datele de interes local pot fi 
stocate şi gestionate local, ceea ce determină reducerea drastică a traficului 
în reţea. Cea mai mare problemă cu care se poate confrunta o bază de date 
centralizată, atunci când ea este accesată de la distanţă, este legată de 
eventualitatea blocajelor reţelei de comunicaţie; nici supraîncărcarea 
serverului de numeroasele accese de la distanţă nu trebuie neglijate. 
Sistemele distribuite oferă timpi de răspuns mai buni la cererile utilizatorilor. 
Sistemele centralizate păcătuiesc adesea prin oferirea unor timpi de răspuns 
nesatisfăcători utilizatorilor, datorită volumului mare de date ce trebuie 
transmise prin reţea. 

In afara avantajelor prezentate, implementarea sistemelor distribuite are 
asociate şi unele dezavantaje ce trebuie luate în considerare la dezvoltarea 
lor. Poate cea mai importantă piedică în extinderea utilizării sistemelor 
distribuite o reprezintă dificultatea dezvoltării lor generată de enorma 
complexitate a acestor sisteme. Principalele surse ale complexităţii sunt: 
distribuirea datelor şi/sau replicarea lor, distribuirea prelucrărilor, asigurarea 
diferitelor forme de transparenţă, asigurarea consistentei datelor. Un sistem 
cu baze de date distribuite care trebuie să ascundă natura distribuită a 
datelor faţă de utilizatori este fără îndoială mai complex decât un sistem cu 
baze de date centralizate. Bazele de date replicate adaugă cel puţin un nivel 
suplimentar de complexitate. Dacă sistemul nu este bine proiectat, atunci el 
va furniza un nivel de performanţă, disponibilitate şi siguranţă inacceptabile. 


1.3.2 Modelul client/server 
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Arhitectura client/server reprezintă modelul arhitectural cel mai utilizat la 
dezvoltarea sistemelor distribuite. El este un model general ce poate fi 
implementat în numeroase moduri. 

Ideea subiacentă conceptului client/server este serviciul. O aplicaţie 
informatică distribuită dezvoltată după modelul client/server este descompusă 
în două două grupuri de procese: consumatorii de servicii, numiţi client şi 
furnizorii de servicii, numiţi server, care comunică între ele prin schimbul de 
mesaje de tip solicitare-răspuns (vezi figura 1.4). De exemplu, un server poate 
fi conceput pentru a oferi un serviciu de baze de date clienţilor săi. Serverul 
este funcţional independent de client, iar relaţia între client şi server este de 
colaborare (cooperare). Ea se diferenţiază radical de aplicaţiile centralizate, 
în care relaţia este de tip “stăpân-sclav” (master-slave). 

În modelul client/server, clientul solicită serverului execuţia unui serviciu 
prin transmiterea unui mesaj. La rândul său, serverul va transmite clientului 
rezultatul solicitării sale. Diferitele funcţii ale aplicaţiei informatice sunt 
regrupate sub forma programelor client şi server, fiecare cu roluri bine 
definite. Pentru utilizator totul este transparent, el comunicând cu programul 
client; schimbul de mesaje realizat între programele client şi server îi sunt 
transparente, el percepând apţieaţaaeaa un ansmablu executat doar pe postul 
său de lucru; ae 
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Figura 1.4 Modelul general al interactiunii dintre client si server 


Problema principala in modelul client/server este legata de distinctia clara 
dintre client şi server. Proiectarea sistemelor client/server presupune 
conceperea arhitecturii aplicaţiilor pe straturi bine definite. O astfel de 
abordare permite proiectarea independentă a straturilor, singura grijă 
constând în definirea clară şi proiectarea atentă a interfetelor, urmărindu-se 
ca: 

+ fiecare strat să aibă un domeniu bine definit, în sensul definirii foarte clare 
a sarcinilor şi responsabilitatilor fiecărui strat; 

+ fiecare strat trebuie să îndeplinească o sarcină specifica; dacă, de exemplu, 
unul din straturi este responsabil cu interacţiunea cu utilizatorul, atunci 
numai acel strat va comunica cu utilizatorul, celelalte straturi realizând 
acest lucru prin intermediul acestui strat dacă au nevoie de informaţii de la 
utilizator. 

+ stabilirea unor protocoale bine definite pentru interacţiunea dintre 
straturi, interacţiune care să se realizeze numai prin intermediul acestor 
protocoale. 

O primă încercare în acest sens a constituit-o împărţirea aplicaţiilor pe 
două straturi, rezultând arhitectura cu două straturi. Această arhitectură 
presupune descompunerea aplicaţiei în următoarele două straturi: stratul 
corespunzător aplicaţiei, în care se include interfaţa grafică cu utilizatorul şi 
implementarea regulilor afacerii (business rules) şi stratul corespunzător 
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bazei de date, care este responsabil de menţinerea integrităţii bazei de date. 
În acest strat poate fi implementată întreaga logică a tranzacţiei sau o parte a 
ei. 

Distincția dintre cele două straturi nu este întotdeauna bine definită 
deoarece logica tranzacţiei este adesea implementată pe serverul de baze de 
date, sub forma procedurilor stocate, iar regulile afacerii, parte a logicii 
aplicaţiei, sunt de asemenea implementate pe server, sub forma trigger-elor. 
În plus, sunt întâmpinate greutăţi considerabile în dezvoltarea sistemului 
informaţional pe baza creşterii accentuate a numărului de aplicaţii, a 
numărului şi tipului serverelor de baze de date. Această deficiență poate fi 
rezolvată prin introducerea unui nivel suplimentar, care să trateze regulile 
afacerii, rezultând o arhitectură cu trei straturi (vezi figura 1.5). Această 
arhitectură presupune împărţirea aplicaţiei în următoarele straturi: 

+ gestiunea interfatei utilizator (gestiunea prezentării) - priveşte 
dialogul între utilizatori şi aplicaţie, incluzând aici logica de prezentare a 
informaţiei (ansamblul prelucrărilor efectuate asupra datelor necesare 
afişarii lor). El acceptă intrările de la utilizator şi furnizează rezultatele 
prelucrărilor în formatul solicitat; 

+ logica aplicaţiei - cuprinde ansamblul operaţiilor de prelucrare 
specifice aplicaţiei şi inlantuirea lor logică; 

+ gestiunea datelor - rezolvă cererile de date, asigură integritatea 
datelor, emiterea anumitor mesaje de alertare, precum şi gestiunea fizică 
a datelor (adăugări, modificări, ştergeri). 


Cerere : 
Gestiunea 
interfetei 


Figura 1.5 Arhitggtura ‘client/server cu irar Stra turi 
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În esenţă, arhitectura pe trei straturi diferă de cea pe două straturi 
prin separarea logicii afacerii într-un strat distinct, localizat de regulă pe un 
server de aplicaţii care comunică strâns cu serverul de baze de date. 
Introducerea unui strat intermediar permite definirea şi implementarea 
regulilor afacerii independent de logica prezentării interfeţei GUI şi a 
regulilor de proiectare a bazei de date. Acest avantaj devine evident în 
condiţiile în care regulile afacerii sunt supuse mai des modificărilor, facilitând 
astfel reimplementarea lor. 

În prezent se manifestă tendinţa dezvoltării aplicaţiilor cu n 
straturi, în care pot exista mai mult de trei straturi, atât din punct de vedere 
logic, cât şi fizic. De exemplu, în figura 1.5 stratul bazei de date sau stratul 
aferent logicii aplicaţiei pot fi împărţite la rândul lor în mai multe straturi. 
Acest lucru este posibil datorită apariţiei unei noi paradigme în dezvoltarea 
sistemelor informaţionale, referită prin sintagma orientată pe componente. 

Implementarea unei aplicaţii multistrat necesită existenţa unor programe 
speciale care să faciliteze comunicarea dintre straturi. Programele care 
facilitează implementarea facilitatilor de comunicare între straturi sunt 
referite prin middleware. O definiţie mai formală, consideră middleware-ul 
ca un nivel al software-ului al cărui scop constă în mascarea eterogenitatii 
platformei hardware şi software, precum şi furnizarea unui model de 
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programare comod dezvoltatorilor de aplicatii*. El este format din procese sau 
obiecte ce se regăsesc pe un grup de calculatoare, şi care interacționează 
între ele pentru a asigura implementarea comunicării şi partajării resurselor 
în aplicaţiile distribuite. Altfel, aplicaţiile distribuite ar trebui să apeleze 
direct la interfaţa de programare furnizată de sistemul de operare al reţelei. 
Pentru a simplifica dezvoltarea şi integrarea aplicaţiilor distribuite, 
majoritatea soluţiilor middleware se bazează pe un anumit model, care 
descrie aspectele privind distribuirea şi comunicarea. Cele mai utilizate astfel 
de modele sunt: apelarea procedurilor de la distanţă (Remote Procedure 
Call), distribuirea obiectelor şi distribuirea documentelor. Cele mai 
cunoscute soluţii middleware sunt Sun RPC, CORBA (Common Object 
Request Broker Architecture), Java RMI (Java Remote Object 
Invocation) si DCOM (Distributed Component Object Model). 


1.3.3 Internet, Intranet si Extranet 


Internetul şi Web-ul devin medii de implementare a aplicaţiilor 
informatice din ce în ce mai populare. De asemenea, Intranetul şi Extranetul 
reprezintă alternative viabile ca medii de dezvoltare a sistemelor informatice. 
În continuare vom încerca să le definim şi să punem în evidenţă principalele 
facilităţi pe care le oferă. 

Internetul reprezintă o colecţie globală de reţele interconectate prin 
intermediul unui standard comun - TCP/IP (Transmission Control 
Protocol/Internet Protocol). Prin intermediul sau sunt oferite numeroase 
servicii: protocoale pentru posta electronica (SMTP, POP, IMAP), protocoale 
pentru transferul fisierelor (FTP), protocoale pentru accesul si executia la 
distanta a proceselor (Telnet, RPC). 

Web-ul este o colectie de resurse (programe, fisiere si servicii) care 
pot fi accesate in Internet prin intermediul unor protocoale standard, precum 
HTML, XML, HTTP, programe executabile standard sub forma scripturilor 
Java sau Visual Basic. Web-ul este organizat conform arhitecturii 
client/server. Resursele Web sunt gestionate de procese server executate pe 
servere dedicate, iar programele client transmit cereri acestor servere 
utilizand protocoalele standard ale Web-ului. Aceste protocoale pot fi utilizate 
şi în programele obişnuite, nu doar browser-ele Web. 

Intranetul este o retea privata care utilizeaza aceleasi protocoale ca 
si Internetul si Web-ul, dar care limiteaza accesul la resurse doar pentru un 
grup de utilizatori. De regula ea este localizata la nivelul unei organizatii. 

Extranetul este un intranet care a fost extins pentru a include alti 
utilizatori din afara organizatiei, cum ar fi furnizorii, clientii, partenerii 
strategici. Astfel, un Extranet permite mai multor organizatii sa schimbe 
informatii si sa-si coordoneze activitatea lor, formand ceea ce se numeste o 
organizatie virtuala. O metoda larg utilizata pentru implementarea unei 
organizatii virtuale o reprezinta retelele private virtuale (Virtual Private 
Network - VPN). O astfel de retea ofera aceleasi avantaje ca si o retea 
privata, adica este securizata si ofera acces doar membrilor organizatiei, insa 
ea este construita deasupra unei retele publice. 

Fara indoiala, Internetul si tehnologiile Web reprezinta o platforma de 
implementare a aplicatiilor foarte atractiva. De exemplu, sa consideram 
problema unui agent de vanzari care-si desfasoara activitatea sa in cea mai 


t Coulouris, G., Op.cit., p.32 
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mare parte pe teren. El are nevoie să acceseze sistemul informatic al firmei 
pentru consultarea bazei de date cu stocuri sau pentru introducerea 
comenzilor. Pentru rezolvarea acestei probleme există mai multe alternative. 
O variantă ar consta în proiectarea unei aplicaţii client/server, din care o 
parte va fi instalată pe serverul firmei, iar cealaltă parte pe laptop-ul 
agentului. Astfel, agentul se va putea conecta la sistem de la distanţă prin 
intermediul unei reţele private şi va putea interoga şi actualiza baza de date. 

O altă variantă ar presupune construirea unei aplicaţii care să permită 
utilizarea unei interfeţe Web pentru accesarea de la distanţă a sistemului. 
Aplicația va poate fi implementată utilizând HTML si va fi executată pe 
serverul Web al firmei, ea putând fi accesată de pe orice calculator conectat 
la Internet utilizând un browser Web. Prin implementarea aplicaţiei Web 
sporeşte accesibilitatea sistemului (sistemul poate fi accesat de oriunde există 
un calculator conectat la Web) şi se elimină nevoia instalării părţii de client a 
aplicaţiei pe laptop-ul agentului. In plus, o astfel de aplicaţie este mult mai 
uşor de modificat, fiind necesară doar modificarea versiunii rezidente pe 
serverul Web. 

O alta facilitate oferită de platforma Internet/Intranet/Extranet 
priveşte integrarea sistemului informaţional. În multe firme funcţionează mai 
multe sisteme informaţionale, fiecare adresându-se unui domeniu funcţional. 
Integrarea acestor sisteme, adesea fiecare cu propria bază de date, se poate 
realiza prin intermediul unui limbaj standard al Internetului, aşa cum este 
XML. XML oferă un standard pentru definirea interfetelor si a comunicaţiei 
între diferite aplicaţii şi baze de date. 

Facilităţile oferite de Internet nu îşi găsesc aplicabilitatea doar la 
nivelul sistemului informaţional dintr-o firmă. Ele oferă oportunitatea definirii 
unor noi moduri de desfăşurarea a afacerilor prin punerea în practică a 
conceptelor business-to-business (B2B) şi business-to-consumer (B2C). De 
exemplu, firmele pot utiliza Internetul pentru a dezvolta relaţiile cu furnizorii 
săi. Aceştia pot utiliza tehnologia Web pentru a interoga datele privind 
stocurile de materiale şi să asigure un nivel minim prestabilit. De asemenea, 
multe firme îşi promovează şi vând produsele prin intermediul site-urilor Web. 

In concluzie, dezvoltarea de aplicaţii Web oferă anumite avantaje în 
comparaţie cu aplicaţiile client/server tradiţionale: 

e Accesibilitatea. Aplicațiile Internet, intranet şi extranet sunt 
accesibile unui mare număr de utilizatori, inclusiv furnizorii şi 
clienţii firmei. 

e Costuri reduse de comunicaţie. În prezent comunicaţia prin 
reţeaua de bază a Internetului nu presupune costuri pentru 
utilizatori, iar conectarea unei reţele LAN private la Internet se 
poate face la preţuri mici prin intermediul furnizorilor de servicii 
Internet. 

e Standarde implementate pe scară largă. Standardele Web sunt 
cunoscute de majoritatea specialiştilor, astfel că dezvoltarea 

A aplicaţiilor Web este relativ mai ieftină. 

Insă, la evaluarea alternativelor de implementare trebuie luate în 
considerare şi aspectele negative ale utilizării standardelor Web şi Internet. 
Acestea, în principal se referă la: 

e Securitatea. Larga accesibilitate şi caracterul deschis al 
standardelor Web fac ca serverele Web să fie mai vulnerabile la 
diverse atacuri. 
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e Siguranţa. Protocoalele de comunicaţie ale Internetului nu 
garantează primirea mesajelor de către destinatar. Au fost 
propuse câteva standarde în acest sens dar nu sunt încă utilizate 
pe scară largă. 

e Rata de transfer. Rețelele furnizorilor de servicii Internet şi cele 
de bază ale Internetului pot fi suprasolicitate în anumite 
perioade, ceea ce determină un timp de răspuns mare în cazul 
accesării unor resurse voluminoase (de exemplu o bază de date 
volumionoasă). 

e Standarde instabile. Standardele Web se schimbă rapid, iar cei 
care se ocupă cu dezvoltarea sistemelor sunt puşi în fata unei 
dileme: să utilizeze ultimele standarde pentru a creşte 
funcţionalitatea aplicaţiilor sau să utilizeze standarde mai vechi 
pentru a asigura o mai bună compatibilitate cu aplicaţiile 
dezvoltate anterior. 


1.4 Generarea şi selectarea alternativei de implementare 


În afara deciziilor privind aria de întindere a sistemului, nivelul de 
informatizare şi mediul de dezvoltare a noului sistem, trebuie aleasă şi 
modalitatea de implementare a soluţiei de sistem. 

Implementarea unei soluţii poate fi realizată în mai multe moduri. De 
exemplu, aplicaţiile standard (cum sunt aplicaţiile de gestiune a stocurilor, 
evidenţa clienţilor, contabilitate generală, resurse umane-salarizare etc.) pot 
fi achiziţionate de pe piaţă de la o firmă producătoare de software. Dacă 
achiziţionarea nu este o soluţie acceptată de firmă, atunci se poate opta 
pentru dezvoltarea noului sistem fie în cadrul firmei de către specialiştii 
proprii, fie prin contractarea unor specialişti din afara firmei pentru 
realizarea unor activităţi care presupun un nivel de expertiză tehnică 
deosebită (cum ar fi proiectarea şi programarea aplicaţiilor web, dezvoltarea 
sistemelor distribuite, dezvoltarea aplicaţiilor data warehouse etc.). Prin 
urmare, există mai multe variante de implementare a soluţiei pentru noul 
sistem, pe care echipa de dezvoltare a noului sistem trebuie să le ia în 
considerare, să le evalueze şi să o aleagă pe cea care corespunde cel mai bine 
condiţiilor din firmă şi caracteristicilor sistemului informaţional. 


Externalizarea 
serviciilor 

informaţionale 
Achizition 
are 

Solutii 
ERP 

Dezvolt 
are 


În cadrul În afara 
firmei firmei 
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Figura 1.6 Alternative de implementare 
(adaptare dupa Satzinger, J.W., Jackson, R.B., Burd, S.D., Systems Analysis and Design in a 
Changing World, Course 'Technology, Thomson Learning, 2002, p.314) 


După cum se poate observa şi din exemplele prezentate anterior, 
numeroasele alternative de implementare a sistemului se regăsesc în spaţiul 
definit de două dimensiuni: prima dimensiune se referă la opţiunea 
achizitionare/dezvoltare, iar cea de-a doua dimensiune priveşte opţiunea în 
cadrul firmei/in afara firmei. Cadrul astfel format şi poziţionarea celor mai 
importante alternative de implementare sunt puse în evidenţă în figura 1.6. 

Fiecare din cele două axe conţin un spectru de valori, nu doar valorile 
extreme evidenţiate în figura 1.6. Se poate opta pentru achiziţionarea 
întregului sistem sau pentru dezvoltarea în totalitate a acestuia însă, între 
aceste două extreme, pot fi identificate şi alte soluţii în care o parte a 
sistemului să fie cumpărată, iar cealaltă parte să fie dezvoltată. De exemplu, 
se poate opta pentru achiziţionarea unei soluţii de pe piaţă, dar care să 
necesite modificarea unor componente sau adăugarea altora în vederea 
adaptării la anumite cerinţe specifice firmei sau pentru crearea interfetelor cu 
sistemele existeente în firmă. În mod similar, există mai multe opţiuni în ce 
priveşte cealaltă dimensiune, situate între cele două extreme: dezvoltarea 
integrală a sistemului în cadrul firmei şi dezvoltarea sa integrală în afara 
firmei. 


1.4.1 Externalizarea serviciilor (outsourcing) 

Externalizarea a devenit una din metodele cele mai eficiente de 
reducere a costurilor şi de îmbunătăţire a performanţelor unui grup de 
activităţi din cadrul firmei. Ideea de bază a externalizării constă în apelarea la 
un agent extern firmei pentru a acţiona în nume propriu. Astfel, 
externalizarea proceselor economice (Business Process Outsourcing 
BPO) constă în delegarea unuia sau mai multor procese economice unui 
furnizor de servicii pentru îmbunătăţirea performanţei economice şi 
reducerea costurilor dintr-un anumit domeniu de activitate al firmei. 
Domeniile de activitate cele mai des externalizate sunt contabilitatea, 
proiectarea producţiei şi sistemele informaţionale. 

Similar BPO,  externalizarea sistemelor informaţionale (sau a 
serviciilor IT) presupune transferul către un furnizor a managementului 
sistemului informaţional, respectiv a dezvoltării şi exploatării sistemului 
informaţional al firmei. Externalizarea sistemelor informaţionale cuprinde un 
spectrum de posibilităţi, de la externalizarea în totalitate a sistemelor 
informaţionale şi până la externalizarea dezvoltării parţiale a noului sistem. 

La o extremă se află situaţia contractării unui agent pentru 
dezvoltarea şi exploatarea aplicaţiilor pe calculatoarele acestuia, firma 
preocupându-se numai de furnizarea datelor de intrare şi preluarea ieşirilor 
sistemului. In acest caz, agentul contractat se va ocupa de toate serviciile 
informaţionale, inclusiv prelucrarea datelor, calculatoarele, programele, 
reţeaua şi personalul aparţinând acestuia. In fapt, agentul va reprezenta 
departamentul informatic al firmei pentru care prestează serviciile. O variantă 
apropiată presupune angajarea unei companii care să furnizeze aplicaţiile 
necesare şi să le execute în cadrul firmei contractante pe calculatoarele 
acesteia. Se poate opta pentru externalizarea doar a activităţilor de 
dezvoltare a sistemelor informaţionale, cu scopul dezvoltării complete sau 
parţiale a sistemului, cumpărării de pachete-program şi, eventual, adaptarea 
acestora la cerinţele specifice ale clientului, sau obţinerea de asistenţă pe 
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parcursul tuturor fazelor de dezvoltare a sistemului. Un exemplu tradiţional 
constă în contractarea unui agent pentru testarea aplicaţiilor la nivel de 
sistem. 

După cum rezultă şi din figura 1.6, în acest paragraf prin 
externalizarea serviciilor IT facem referire la întregul sistem, inclusiv punerea 
în funcţiune şi exploatarea sa de zi cu zi. Situaţia contractării unei firme doar 
pentru dezvoltarea noului sistem sau a unei părţi din acesta nu se încadrează 
aici; ea este evidenţiată în acea parte a formei „Soluţia dezvoltării” care 
corespunde opțiunii „In afara firmei”. 

Dar de ce ar apela o firmă la externalizarea serviciilor sale 
informaţionale? În primul rând ea poate obţine o importantă reducere a 
costurilor. O companie specializată în oferirea de servicii informaţionale 
beneficiază de economiile de scară obţinute prin rularea aplicaţiilor sale 
pentru mai multe firme, şi va putea să-şi ofere serviciile la preţuri reduse. Pe 
de alta parte, prin  externalizare firmele urmăresc îmbunătăţirea 
performanţelor serviciilor sale informaţionale, companiile specializate 
dispunând de experienţa şi expertiza pe care celelalte firme nu le au. În plus, 
se obţine şi împărţirea riscurilor inerente asociate investiţiilor în tehnologiile 
informaţionale între firmele partenere. 

Externalizarea sistemelor informaţionale reprezintă, în general, o 
decizie strategică, pe termen lung (de regulă 8-10 ani), şi nu se aplică doar 
asupra unui proiect de dezvoltare ci la nivelul întregii organizaţiei. De aceea, 
ea nu reprezintă propriu-zis o alternativă de implementare a sistemelor 
informaţionale, decizia nefiind luată în mod normal de echipa de realizare a 
proiectului ci la nivelul conducerii superioare. 

Oricum, analiştii trebuie să ia în considerare externalizarea. La 
generarea alternativelor strategice de dezvoltare a sistemului, analistul 
trebuie sa consulte firmele specializate în furnizarea de servicii 
informaţionale. Este posibil să existe o cel puţin o firmă care să fi dezvoltat 
deja şi să ruleze un sistem care să corespundă cerinţelor utilizatorilor noului 
sistem. Pentru a putea lua o astfel de decizie, analistul trebuie să cunoască 
foarte bine cerinţele sistemului pentru a evalua măsura în care un furnizor de 
servicii informaţionale poate răspunde acestor cerinţe. 

Externalizarea serviciilor informaţionale este posibilă prin apelarea la 
Application Service Providers (ASP). Un ASP este o companie care 
dezvoltă şi furnizează servicii folosite în comun de mai mulţi utilizatori, care 
plătesc un abonament sau taxe de folosire, serviciile fiind furnizate dintr-o 
locaţie centrală prin Internet sau printr-o reţea privată. ASP presupune acces 
partajat, sub control, la anumite servicii. Ca beneficii pot fi menţionate 
investiţiile iniţiale modeste si predictibilitatea costurilor, posibilitatea de a fi 
mereu în ton cu progresele tehnologice. Avantajele sunt multiple: 

e posibilitatea închirierii aplicaţiilor scumpe, inaccesibile companiilor 
mici şi mijlociii sau a celor cu investiţii iniţiale importante; 

e acces la suport tehnic şi consultanţă de specialitate, pentru servicii 
cu înalt nivel tehnologic; 

e posibilități de upgrade continue; 

e aplicaţii funcţionale într-un interval de timp foarte scurt. 


1.4.2 Surse ale software-ului 


Dacă soluţia externalizării serviciilor informaţionale ar putea pare una 
prea radicală, firmele au la dispoziţie şi alte alternative de implementare a 
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sistemului; ne referim la diferitele surse ale software-ului (la o adică software- 
ul este cea mai importantă componentă a sistemelor informaţionale, nu?). În 
general, aplicaţiile informatice pot fi obţinute pe două căi principale: achiziţia 
unui pachet de aplicaţii de pe piaţă de la diferiţi furnizori, numit şi soft la 
cheie, sau dezvoltarea acestuia prin parcurgerea tuturor fazelor specifice 
ciclului de viaţă al sistemelor informaţionale, soluţie numită şi soft la 
comandă. Aceste două metode nu reprezină decât valorile extreme ale unui 
spectru imaginar. Între cele două extreme mai pot fi identificate alte soluţii, 
precum softul la cheie modificat. Diferitele căi de obţinere a software-ului 
vor fi prezentate în continuare. Vom pune accentul pe analiza avantajelor şi 
dezavantajelor asociate fiecăreia în parte, prezentate sintetic în tabelul 1.3. 


Software-ul la cheie 

Softul la cheie este realizat de către companii specializate în 
producerea de software şi este achiziţionat pentru sprijinirea unui domeniu de 
activitate sau a unei funcţii (financiar-contabilă, producţie, resurse umane 
etc.). El este vândut pe piaţă pentru o mare diversitate de utilizatori cu 
cerinţe similare. Prin definiţie, un astfel de program este utilizat ca atare, fără 
efectuarea de modificări. Oferta de programe este diversă, acoperind 
majoritatea segmentelor de piaţă, de la programe generalizate, precum cele 
pentru contabilitate, până la cele ultra-specializate, cum ar fi cele pentru 
evidenţa pacienţilor unui cabinet medical. 

Avantajele acestui tip de software sunt legate de preţul lor avantajos 
pentru facilităţile pe care le oferă (acelaşi produs este vândut mai multor 
firme ceea ce duce la obţinerea economiilor de scară), documentaţia bună şi 
rata redusă de erori. Insă, unele pachete de programe nu pot fi modificate 
pentru a satisface unele cerinţe particulare ale firmei cumpărătoare. Chiar 
dacă majoritatea firmelor realizează funcţii similare, nu există două firme care 
să realizeze aceeaşi activitate în mod identic. Prin urmare, softul la cheie sunt 
destul de bune pentru obţinerea unui anumit nivel de performanţă, însă ele nu 
vor corespunde în totalitate manierei de lucru din firmă, aceasta fiind nevoită 
să-şi adapteze procedurile de lucru. Se estimează că, în cele mai fericite 
cazuri, un soft la cheie poate satisface doar 70% din cerinţele organizaţiei”. 


Tabelul 1.3 Prezentare comparativă a surselor de obţinere a software-ului 
(prelucrare după Oprea, D., Analiza şi proiectarea sistemelor informaţionale economice, 


Polirom, laşi, 1999,p.281-282) 


Modalitat Avantaje Dezavantaje 
ea de 
obtinere a 
software- 
ului 
Soft la 1. Cost mai redus fata de 1. Nu corespund in intregime 
cheie celelalte variante cerintelor utilizatorilor 
2. Timpi de aşteptare până la 2. Nu oferă posibilitatea 
darea în folosinţă foarte mici specialiştilor firmei să le modifice 
3. Documentatia lor este mai 3. Modificarea acestor programe 
buna este scumpa 
4. Firma nu are nevoie de mulți 4. Există riscul ca furnizorul să dea 
specialişti pentru dezvoltarea şi faliment şi astfel programele nu mai 
întreţinerea sistemului pot fi întreţinute 
informaţional 5. Evaluarea programelor de pe 


5 Hoffer, J.A., George, J.F., Valacich, J.S., Modern Systems Analysis and Design, second 
edition, Addison-Wesley, 1999, p. 395 
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5. Programele sunt mai puţin piaţă înseamnă consum de timp şi de 
producătoare de erori, ele fiind bani 
testate anterior de alţi cumpărători 
Soft la 1. Programele raspund cu 1. Este foarte scump 
comanda exactitate cerinţelor uitilizatorilor 2. Dureaza mult pana la punerea sa 
2. Firma poate functiona in functiune 
conform caii dorite si nu cum o 3. Probabilitate mai mare de 
impun programele cumparate aparitie a erorilor 
3. Integrarea mai usoara cu alte 4. Solicita prea mult angajatii si 
programe ce ruleaza in firma conducerea firmei 
4. Loialitatea utilizatorilor față 5. Documentaţia este slabă sau, de 
de propriul sistem este mult sporită | multe ori, inexistentă 
Soft la 1. Răspunde mai bine la 1. Modificarea programelor este în 
cheie cerințele utilizatorilor decât softul sine o activitate dificilă, ea putând 
modificat la cheie produce erori logice şi efecte 
2. Firma poate lucra conform neaşteptate 
modalităţii pe care şi-o doreşte 2. Unii furnizori nu acceptă 
3. Sunt mai ieftine şi solicită modificarea programelor lor 
mai puțin timp decât softul la 3. Documentaţia despre modificări 
comandă poate fi incompletă sau inexistentă 


O variantă a softului la cheie sunt aşa numitele sisteme la cheie. 
Sistemele la cheie sunt soluții complete furnizate de companiile specializate 
care combină programele şi echipamentele; utilizatorul nu trebuie decât să 
răsucească cheia pentru a pune sistemul în funcţiune. 

Până nu demult, software-ul şi sistemele la cheie erau specializate, ele 
fiind concepute pentru sprijinirea unui departament/functiuni din cadrul 
organizaţiei. Pentru informatizarea mai multor departamente/functiuni, se 
achizitionau mai multe programe la cheie, fiecare fiind destinat unui anumit 
domeniu de activitate, dar care rareori puteau fi integrate, ele fiind 
achiziţionate de la producători diferiţi. Efectele acestei strategii s-au 
concretizat în existenţa aşa numitor „insule informaţionale”, lipsa integrării 
afectând performanţele sistemului informaţional din firmă şi, implicit, ale 
celorlalte activităţi ale firmei. Au existat numeroase încercări de integrare a 
aplicaţiilor utilizate de diferite departamente din organizaţii, însă răspunsul 
complet la nevoia de integrare l-au reprezentat soluţiile ERP (Entreprise 
Resource Planning). 

ERP reprezintă o mega-aplicatie multi-modulară care integrează 
procesele economice şi optimizează resursele disponibile ale întreprinderii, 
reunind toate funcțiunile sale într-o singură soluţie software. ERP înseamnă 
integrarea tuturor aplicaţiilor într-o soluţie globală, acoperind toate procesele 
organizaţiei, eliminând graniţele dintre departamente şi funcțiuni, ca şi pe 
cele ale organizaţiei cu mediul său. Astfel, din punct de vedere funcţional, 
modulele ERP acoperă planificarea şi urmărirea producţiei, gestiunea 
achiziţiilor, gestiunea stocurilor, gestiunea resurselor umane, gestiunea 
relaţiilor cu clienţii şi furnizorii, gestiunea financiar-contabilă etc. 

Din punct de vedere tehnologic, ERP se fundamentează pe arhitectura 
client/server cu trei straturi, însă aceste soluţii integrează şi alte tehnologii 
informaţionale, precum workflow, workgroup, groupware, EDI (Electronic 
Data Interchange), Internet, Intranet, data warehouse etc. Aşadar, soluţiile 
ERP realizeaza nu doar o integrare functionala ci si una tehnologica, tocmai 
pentru a realiza integrarea functionala completa. 

O solutie ERP se individualizeaza prin urmatoarele caracteristici cheie: 

> Flexibilitate, in sensul ca raspunde cerintelor de schimbare ce 
pot apare oricand intr-o organizatie; 
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> Modularitate şi deschidere, care se referă la posibilitatea si 
uşurinţa renunţării, înlocuirii sau adăugării unui nou modul fără 
să afecteze celelalte module; 

> Evolutivitate, în sensul că permite adoptarea tehnologiilor 
viitoare, tocmai datorită celor două caracteristici enumerate 
anterior, modularitatea şi caracterul deschis; 

> Standardizare, suportand diverse platforme hardware şi 
software datorită adoptării arhitecturii client/server pe trei 

_ straturi ce apelează la soluţiile middleware. 

In afara avantajelor derivate direct din caracteristicile amintite 
anterior, soluţiile ERP mai oferă alte numeroase avantaje, precum: reducerea 
costurilor producţiei şi stocurilor, planificarea integrală a resurselor 
întreprinderii, îmbunătăţirea productivităţii globale, maximizarea 
profitului prin flexibilitate şi reactivitate sporită la cerinţele pieţei. 

Dincolo de avantajele lor evidente, apelarea pe scară largă la soluţiile 
ERP nu este deocamdată o realitate, situaţie explicabilă prin trei mari 
neajunsuri: preţul exorbitant de mare, timpul îndelungat de 
implementare şi adaptabilitatea lor la condiţiile din firmă. În consecinţă, 
optarea pentru implementarea unei soluţii ERP implică unele riscuri pentru 
întreprindere legate de volumul mare al investiţiilor iniţiale, costuri ascunse 
semnificative, incertitudini privind adaptabilitatea ei şi responsabilitatile 
sporite încredințate personalului. 

Complexitatea şi amploarea acestor soluţii le face foarte scumpe, cel 
puţin deocamdată. Conform statisticilor, costul implementării unei soluţii ERP 
pe utilizator este cuprins între 1000$ şi 8000$, fiind chiar mai ridicat în cazul 
companiilor foarte mari. Preţul final depinde în principal de dimensiunile 
organizaţiei, de numărul de utilizatori şi numărul componentelor suplimentare 
solicitate şi variază între 400.000 $ şi 300 milioane $. 

Aria mare de adresare (de regulă întreaga întreprindere) şi adaptarea 
lor la cerinţele specifice ale organizaţiei reprezintă pentru soluţiile ERP o 
provocare majoră şi solicită un timp de implementare îndelungat. Trebuie 
efectuată analiza sistemului informaţional din întreaga întreprindere pentru a 
se identifica cerinţele exacte ale sistemului, în funcţie de care se va realiza 
modificarea unor module, testarea şi documentarea acestor modificări. 
Conform unui studiu AMR Research, implementarea unei soluţii ERP durează 
între 9 şi 12 luni într-o firmă mică, între 12 şi 24 de luni pentru firmele mari şi 
până la 3 ani în cazul companiilor foarte mari. Subestimarea timpului cerut de 
implementare este una din capcanele în care cad atât furnizorii, cât şi 
beneficiarii soluţiilor ERP. 

După cum spuneam anterior, unul din dezavantajele softului la cheie 
constă în neadaptarea completă la cerinţele organizaţiei. În cazul soluţiilor 
ERP, acest neajuns se accentuează. Chiar şi după adaptarea programelor vor 
exista incompatibilitati între cerinţele utilizatorilor şi funcţionalitatea pe care 
o oferă. De aceea, în multe situaţii firmele vor trebui să-şi modifice 
procedurile interne de lucru, ceea ce necesită instruirea utilizatorilor şi poate 
determina apariţia unor probleme comportamentale ale utilizatorilor. 

Ascensiunea fulminantă a e-business reprezintă o provocare pentru 
furnizorii de soluţii ERP. Ei trebuie să se adapteze rapid noilor curente de 
integrare inter şi intra-întreprindere. În conformitate cu tendinţa adoptării 
modelului Business-to-Business, se vorbeşte de platforme ERP-to-ERP, numite 
şi Entreprise Application Integration (EAI). Daca ERP realizează 
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integrarea în cadrul firmei, EAl presupune integrarea între firmele partenere, 
punându-se în practică conceptul de sistem informational inter-organizational. 


Software-ul realizat la comandă 

In cazul în care nici unul din produsele existente pe piaţă nu satisface 
cerinţele funcţionale ale utilizatorului, firma nu are altă alternativă decât 
dezvoltarea propriului sistem, urmând întregul ciclu de viaţă al sistemelor. În 
acest sens firma se poate baza pe propriul personal, poate angaja specialişti 
(consultanţi) din afara firmei sau poate opta pentru o soluţie mixtă. De aceea, 
forma corepunzătoare acestei categorii de software din figura 1.6 se întinde 
în ambele cadrane ale dimensiunii „În afara firmei/În cadrul firmei”. 

Principalul avantaj al softului la comandă este că el corespunde cu 
exactitate cerinţelor funcţionale şi nefunctionale ale utilizatorilor. Sistemul va 
fi adaptat la procedurile interne de lucru şi nu invers, ca în cazul softului la 
cheie. Gradul de implicare a utilizatorilor în dezvoltarea sistemului este 
incomparabil mai mare, ceea ce sporeşte loialitatea lor faţă de sistem şi 
diminuează riscul apariţiei problemelor comportamentale. De asemenea, 
organizaţia va acumula o importantă experienţă şi expertiză în dezvoltarea 
sistemelor informaţionale, mai ales în cazul echipelor mixte formate din 
specialiştii proprii şi cei din exterior. Prin angajarea de consultanţi, firma va 
beneficia de cunoştinţele şi experienţa acestora în domeniul de activitate 
respectiv (de exemplu gestiunea resurselor umane) sau în problema de 
rezolvat. 

Dezavantajele principale ale acestei categorii de software sunt legate 
de costurile mari şi timpul îndelungat până la punerea în funcţiune. Dacă 
firma nu dispune de expertiza necesară sau de personal suficient atunci va 
apela la angajarea de consultanţi de la firmele de specialitate, ceea ce va duce 
la o creştere substanţială a costurilor prin salariile mari ce trebuie plătite 
acestora. Spre deosebire de softul la cheie, în care timpul de aşteptare până 
la punerea în funcţiune este aproape nul, în cazul softului la comandă acesta 
este foarte mare, deoarece trebuie parcurse toate fazele ciclului de viaţă al 
sistemelor. In plus, există o probabilitate mare de apariţie a erorilor imediat 
după punerea în funcţiune, chiar dacă s-au efectuat activităţile de testare 
(după cum vom vedea ulterior, testarea exhaustivă este imposibilă), ceea ce 
poate afecta serios performanţele firmei. 

Astăzi, în majoritatea firmelor coexistă softul la cheie, pentru 
domeniile de activitate uşor generalizabile, şi softul realizat la comandă, 
vizând domeniile de activitate mai particulare pentru care există puţine soluţii 
pe piaţă. Trebuie reţinut că dacă se optează pentru softul la cheie, atunci 
alegerea trebuie făcută după încheierea fazei de analiză, iar în cazul softului 
la comandă vor trebui parcurse toate fazele ciclului de viaţă al sistemelor. 


Software-ul la cheie modificat 

Ambele variante de obţinere a software-ului prezentate anterior au 
asociate avantaje şi dezavantaje. O soluţie de compromis, care presupune 
combinarea avantajelor celor două variante, o reprezintă achiziţionarea 
softului (programelor) la cheie şi modificarea lui conform unor cerinţe anume. 
Există firme care acceptă modificarea programelor lor pentru a veni în 
întâmpinarea solicitărilor clienţilor. Această problemă nu mai există în cazul 
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soluţiilor ERP. Modificarea softului la cheie poate fi efectuată de către 
furnizor sau, în cazul în care sunt livrate şi programele sursă, de către firma 
cumpărătoare sau specialişti ai alte firme de soft angajaţi de aceasta. 

Deşi s-a urmărit eliminarea dezavantajelor asociate celorlalte două 
categorii de software, şi această variantă implică unele dezavantaje, dupa 
cum rezultă din tabelul 1.3. In principal, ele sunt legate de dificultatea 
activităţii de modificare a programelor în general, precum şi de costurile mari 
pe care le pot implica dacă modificările sunt mai ample. 


1.4.3 Selectarea alternativei de implementare 


După prezentarea anterioară, se pune întrebarea: Care metodă de 
obţinere a softului este mai bună? Uneori, selectarea unei alternative de 
implementare este simplă, dar de cele mai multe ori reprezintă o sarcină 
dificilă, mai ales în condiţiile diversificării continue a ofertei de produse şi 
servicii informaţionale de pe piaţă. De exemplu, o soluţie poate fi ieftină, dar 
nu acoperă toate funcțiunile cerute. Altă soluţie poate satisface toate cerinţele 
funcţionale dar rulează pe platforme hardware şi software nedorite sau 
implică o perioadă prea mare de implementare. Dificultatea acestei activităţi 
este sporită de numărul mic de puncte comune între diferitele alternative, 
cum ar fi între variantele de externalizare şi dezvoltarea sistemului în cadrul 
firmei sau între soluţiile diferiților furnizori. 

Cu toate acestea, analistul va trebui să identifice un set de criterii 
comune care să permită compararea cât mai exactă a alternativelor de 
implementare viabile. Este evident că nu toate criteriile se pot aplica tuturor 
alternativelor, însă există trei aspecte majore care trebuie luate în 
considerare“: 

> Cerinţele generale, 
> Cerintele functionale si 
> Cerintele tehnice. 

Cerintele generale privesc unele consideratii care nu au legatura 
directa cu sistemele informatice, dar care sunt importante. In primul rand, 
este vorba despre analizele de fezabilitate, puse in discutie in faza de analiza. 
Fiecare alternativa luata in considerare trebuie sa fie fezabila din punct de 
vedere economic, tehnic, juridic si al programării in timp. Pentru alternativele 
de externalizare se vor lua in considerare criteriile de evaluare a furnizorilor, 
a stabilitatii si performantelor sale. In cazul alternativelor de dezvoltare in 
cadrul firmei se va tine seama de riscurile asociate proiectelor de dezvoltare a 
sistemelor informaţionale, precum timpul solicitat sau personalul de 
specialitate disponibil. Câteva dintre criteriile care pot fi considerate aici sunt 
prezentate în tabelul 1.4. 


Tabelul 1.4 Criterii de evaluare a alternativelor de implementare 


Cerinţe generale Cerinţe tehnice 
Performanţele înregistrare te furnizor Robustetea (siguranţa în funcţionare) 
Garantiile şi facilităţile de service Frecvența erorilor 

acordate de furnizor Calitatea programelor (uşurinţa întreţinerii) 
Angajaţii cu experienţă disponibili Calitatea documentaţiei 
Costul dezvoltării Usurinta instalării 
Valoarea beneficiilor aşteptate Flexibilitatea (uşurinţa adăugării unor noi 
Timpul necesar până la punerea în funcţionalităţi) 


5 Satzinger, J.W., Jackson, R.B., Burd, S.D., Systems Analysis and Design in a Changing World, 
Course Technology, Thomson Learning, 2002, p.317 
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funcţiune Usurinta în exploatare (interfeţe prietenoase) 


Costurile estimate pentru conversia Performanţe (timpul de răspuns) 
datelor Compatibilitatea cu platforma hardware şi 
Impactul asupra firmei (instruirea software 


utilizatorilor, schimbarea procedurilor 
interne etc) 


Cerinţele funcţionale se referă la funcţiile pe care trebuie să le 
îndeplinească sistemul. Aceste cerinţe au fost identificate în faza de analiză şi 
se regăsesc structurate în diagramele fluxurilor de date sub forma proceselor 
şi subproceselor. 

În afara cerinţelor generale şi funcţionale, fiecare sistem trebuie să 
îndeplinească anumite cerinţe tehnice. Această categorie include toate 
celelalte cerinţe ale sistemului şi privesc modul său de operare, performanţele 
sale etc. O listă a criteriilor care pot fi încadrate în categoria cerinţelor 
tehnice este prezentată în tabelul 1.4. 

După identificarea criteriilor de comparaţie a alternativelor de 
implementare urmează să se stabilească importanţa relativă a fiecăruia. 
Unele criterii sunt mai importante pentru organizaţie decât altele. De 
exemplu, firma poate dori să cumpere doar de la un furnizor cu reputaţie, cu 
multă experienţă; în altă situaţie este posibil să existe suficient timp la 
dispoziţie până la punerea în funcţiune a noului sistem aşa că restricţiile de 
timp nu reprezintă o cerinţă critică Trebuie determinate nu doar importanţa 
relativă a criteriilor în cadrul categoriei din care fac parte, ci şi importanţa 
relativă a categoriilor de cerinţe. O firmă poate considera mai importante 
cerinţele generale decât cele funcţionale. Oricum, această activitate 
reprezintă partea cea mai dificilă a selectării alternativei de implementare. 

Odată identificate criteriile de evaluare şi determinată importanţa lor 
relativă, se trece la evaluarea fiecărei alternative prin acordarea unei note 
pentru fiecare criteriu, ponderarea notei cu factorul ce reprezintă importanţa 
sa relativă şi însumarea rezultatelor obţinute pentru fiecare criteriu în parte 
pentru a se calcula punctajul total. Va fi selectată alternativa cu punctajul cel 
mai bun. 


1.4.4 Exemplu privind definirea şi evaluarea alternativelor de 
implementare 


În tabelul 1.5 sunt prezentate pentru trei variante de implementare, 
criteriile de evaluare, importanţa specifică a acestora şi modul de evaluaare a 
alternativelor şi selectarea celei mai bune alternative de implementare. S-a 
utilizat o scară de la O la 5 atât pentru reliefarea importanţei relative a 
criteriilor de evaluare, cât şi pentru evaluarea fiecărui criteriu. 


Tabelul 1.5 Evaluarea alternativelor de implementare 
Importan| Alternativa 1 | Alternativa 2 | Alternativa 3 


Criterii de ta (soft la (soft la cheie) (soft la 
evaluare specifica] comandă - în comanda - 
firma) specialisti din 
alta firm) 

Criterii generale 
Existenta 4 3 12 4 16 5 20 
personalului 
specializat 
Costul dezvoltării 5 4 20 2 10 5 25 
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Valoarea aşteptată | 5 5 25 3 15 4 20 

a beneficiilor 

Timpul de 4 3 12 5 20 2 8 

dezvoltare 

Garantii şi service | 3 5 15 3 9 3 9 

Total criterii 84 70 82 

generale 

Criterii functionale 

Inregistrarea 5 5 25 3 15 5 25 

comenzii 

Crearea 4 5 20 0 0) 5 20 

materialelor 

promotionale 

Determinarea 3 5 15 0 0 5 15 

profilului clientilor 

Urmarire clientiin | 3 5 15 5 15 5 15 

litigiu 

Analiza vanzari 3 5 15 0 0 5 15 

Controlul 5 5 25 5 25 5 25 

stocurilor 

Generarea notei 4 5 20 5 20 5 20 

contabile 

Avizare comenzi 4 5 20 0 0 5 20 
Total criterii 155 75 155 
funcționale 

Cerințe tehnice 

Robustetea 5 3 15 5 25 3 15 

Erori de 4 3 12 4 16 3 12 

programare 

Calitatea codului 4 4 16 5 20 4 16 

Documentatia 3 3 9 5 15 3 9 

Usurinta instalarii | 2 5 10 4 8 4 8 

Calitatea interfetei | 4 5 20 4 16 5 20 

Total criterii 82 100 80 

tehnice 

Total general 321 245 317 


Din tabelul 1.5 rezulta ca alternativa cea mai buna o constituie 
dezvoltarea sistemului cu proprii specialisti. Varianta achizitionarii softului la 
cheie este cea mai slaba, datorita faptului ca multe din cerintele functionale 
ale sistemului nu sunt satisfacute de programele existente pe piata. Pentru 
varianta a doua a fost luat in considerare cel mai bun program de pe piata. O 
altă variantă care putea fi luată în calcul o reprezenta modificarea 
programului achiziţionat de pe piaţă. 

1.5 Pentru a merge mai departe (privire de ansamblu asupra 
ceea ce urmează) 


Odată aleasă strategia de proiectare urmează proiectarea detaliată a 
sistemului: proiectarea BD, a interfeţelor, a arhitecturii programelor în 
funcţie de strategia aleasă. Apoi urmează implementarea: scrierea 
programelor, testarea, conversia. 

Care ar fi ordinea de abordare: BD, formulare şi dialoguri, rapoarte, 
programe. Intrări- baza de date - prelucrări -iesiri? 

Care sunt principiile generale de proiectare? Am putea formula unul 
nou: utilizarea formalismelor (instrumentelor) grafice. 
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Subiecte 


1. 
2. 


NO Ul 


Idei 
1 


Comentati figura cu categoriile de software 

Sunteţi puşi în situaţia de a argumenta o alternativă de implementare în 

fata conducerii firmei. Schitati un dialog în care să prezentaţi 

argumentele în favoarea alegerii dvs. 

. Formulati, evaluati şi selectaţi alternativa de proiectare (implementare) 
pentru sistemul din studiul de caz. 

. Cum se poate pune în evidenţă diferenţa între prelucrarea pe loturi şi 
prelucrarea on-line în cadrul diagramei fluxurilor de date? 

. Explicaţi rolul DFD în definirea strategiei de proiectare. 

. Cum poate fi diferențiată analiza de proiectarea unui sistem informatic? 

. Specificaţi rolul pe care-l joacă DFD-urile de-a lungul proiectării şi 

implementării noului sistem (delectarea alternativelor de proiectare, 

proiectarea interfetelor, proiectarea programelor, testarea). 


de inclus: 

. Using automation boundaries to identify alternatives requires expertise 
in data flow diagrams. The techniques described in this chapter require 
a complete logical model consisting of a set of balanced data flow 
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diagrams and supporting documentation. A logical model consisting of a 
data flow diagram (Figure 36.1) and associated documentation (Chapter 
24) is the starting point for generating alternatives using automation 
boundaries 

. Many CASE products include routines that allow a user to graphically 
define automation boundaries on a data flow diagram. The examples in 
this chapter were prepared using Visio 
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